Day 05：先把工具搞清楚——Claude 生態的名詞地圖，與我的實際分工

前幾天都在講「怎麼跟 AI 協作」，但有個更前面的問題該先解決：Claude 這一整套工具，到底誰是誰、該怎麼分工？ 名詞先理清楚，後面的實戰才不會霧煞煞。今天這篇當一張地圖，也順便講我自己怎麼切。

一、七個名詞，先對齊

我用一句話講清楚每個是什麼、綁著什麼脈絡：

• Chat（claude.ai 對話）：最基本的對話視窗。脈絡是「這一場對話」，關掉就結束。適合一次性的討論、發想、問答。但它有個常被低估的用法——討論的產出可以是一份規格文件或一段寫好的 prompt，不是聊完就丟。我常在 Chat 裡把「這個功能該怎麼做、有哪些邊界、要注意什麼」討論到收斂，讓它輸出一份規格，再把這份規格交給 Claude Code 去實作。Chat 負責「想清楚要做什麼」，Code 負責「把它做出來」，中間靠這份文件銜接。
• Claude Code：跑在你電腦上的版本，能讀寫檔案、執行終端機指令。脈絡是「你的程式碼 + 檔案系統」，對整個專案的掌握最完整。工程師的主戰場。
• Cowork：偏桌面端的協作環境，綁著「一個實際的工作資料夾」。有明確產出物的持續性工作（文件、報告、素材）放這裡，檔案直接進出。
• CLAUDE.md：放在專案根目錄的一份文件，Claude Code 每次啟動都會自動讀進去。用來寫這個專案的規則、慣例、決策理由，讓每個 session 都自動遵守。（怎麼寫、寫什麼，後面有專章。）
• Project：claude.ai 裡的一個「空間」，可以設定一次自訂指示、放一份知識庫，該空間底下每個對話都自動帶著，不用每次重講背景。角色跟上面的 CLAUDE.md 很像，只是在 claude.ai 這邊。
• Skill 和 MCP：這兩個是「擴充能力」的機制。Skill 是把一套「怎麼做」的步驟固化下來，讓 Claude 照著做；MCP 是讓 Claude 連接外部服務、直接去取資料或操作工具（例如接上瀏覽器控制，或接上一份跨 session 的共享筆記 HackMD）。下面各給實例。

二、Skill：把你重複做的事，固化成一套流程

Skill 對我的意義，是把「我每次都要教 AI 一遍的流程」寫成一份固定指引，之後一句話就能喚起。舉幾個我實際在用的：

• db-to-sequelize：連上資料庫、讀取指定資料表的 schema，自動產生對應的 Sequelize model（含型別對應、命名慣例）。以前我要跟 AI 解釋一整套規則，現在一句「幫我把這張表產成 model」就好。
• merge：把分支合併的固定流程包起來。
• publish：把「哪些檔案該發佈到哪個資料夾」的規則固化，用 git diff 抓變更再發佈。

這三個有個共同點：流程固定、邊界明確、我會重複做。 這正是 Skill 的最佳使用時機——不是什麼都做成 Skill，而是那些「你已經做熟、每次步驟都一樣」的事，固化下來省得每次重講。

三、MCP：補上工具「本身做不到」的能力

MCP 跟 Skill 最大的差別是：Skill 是把 Claude 本來就會的事固化，MCP 是接上 Claude 本來搆不到的外部能力。 兩個我實際用到的情境：

• Playwright MCP（瀏覽器控制）：Claude Code 本身沒辦法操作瀏覽器，但接上 Playwright MCP 之後，它就能直接控制瀏覽器、自動截圖。這對我做操作手冊很有用——以前要手動截圖再貼進去，現在它自己截。
• HackMD MCP（跨 session 的共享筆記）：這個我先賣個關子，因為它解決的是一個更根本的痛點，後面會專篇展開。

判斷準則很簡單：如果一件事你現有的工具「換個方式也做得到」，那不需要 MCP；只有當它是工具「本身做不到」的能力（像瀏覽器控制），MCP 才真正該出現。

四、我的實際分工，與一個藏在裡面的痛點

理清楚之後，我自己的切法是這樣：碰程式碼 → Claude Code；非程式碼但要持續累積產出 → Cowork；純討論、發想 → Chat 開新 session。 每種工作流進對應的工具，不硬湊。這裡有個原則我想強調——工具遷就工作流，不是反過來。你不該為了「用滿所有功能」去改變做事方式，而是看你的工作長什麼樣，再挑最貼的工具。

但這個分工用久了，會撞到一個痛點：這些工具之間，脈絡是不互通的。

我在 Chat 裡討論出的結論，Claude Code 不會自動知道。我可以請 Chat 把討論收斂成一份規格文件（整理這件事它很擅長），但那份文件終究得由我手動搬到 Code 那邊——產出規格是 AI 做的，跨工具搬運這一步目前還是人在做。而且今天這個 session 解決的問題，明天開新 session 又是一張白紙。Project 也一樣——它像「掛著白板的會議室」，白板上的規則每次開會都看得到，但會議記錄不會自動上白板，要你自己寫上去。

這個「跨 session、跨工具的記憶怎麼共享」的問題，是我後來花很多力氣解決的。簡單說，我把它拆成兩類分開處理：固定的規則交給 CLAUDE.md，動態的討論記憶交給 HackMD 這類共享筆記。這兩個解法後面都各有專章完整拆解，這裡先埋個伏筆。

（順帶戳破一個常見迷思：市面上有課程教你建「AI 團隊」——NORA 當營運長、MAYA 寫文案、LEON 分析數據，層層派工。實際上有用的不是「人設」，是背後的「拆分脈絡」和「固化 prompt」——這其實就是 Project 和 Skill 在做的事。名字和頭像是行銷包裝，「營運長派工」對個人使用者常常只是多一層資訊耗損。與其糾結幫 AI 取什麼名字，不如把脈絡切乾淨、把好用的 prompt 存成 Skill。）

這一天的分工

今天沒有 AI 犯錯的戲。但它其實展示了協作裡很日常的價值——AI 很擅長把每個工具的定位、限制攤開來解釋。而「我的工作流長什麼樣、該怎麼切脈絡、哪些流程值得固化成 Skill」，這些決定只有握著自己工作全貌的人能下。

還有一個我想留下的視角：工具之間的「隔離」——各 Project、各 session 互不相通——很多人當它是缺點，我反而當 feature。程式開發本來就各專案獨立，這種隔離讓我不用擔心 AI 把 A 專案的東西攪進 B 專案。期待 AI「記住我所有事情」的用法才需要擔心串味；把隔離當 feature，反而跟工具的實際設計對齊。 真正該跨 session 保留的東西，就用明確的機制去接——固定規則寫進 CLAUDE.md，動態記憶放進共享筆記——而不是指望它自己記得。這才是可靠的做法。

明天談 token——一個很少人算、但一直在花的成本。什麼時候該讓 AI 讀更多、什麼時候該精簡，以及為什麼「裝上所有能力」反而會拖累它。我還會介紹一個很少人分享的內建指令 /doctor，它能幫你把這筆帳算得清清楚楚——順便示範我怎麼抓出它其中一條建議的盲點。